“终于懂了” 系列：Android屏幕刷新机制—VSync、Choreographer 全面理解！
阅读本篇可能需要的预备知识《View的工作原理》、《Handler：Android消息机制》、《Window和WindowManager》、《Activity的启动过程详解》
一、背景和疑问
在Android中，当我们谈到 布局优化、卡顿优化 时，通常都知道 需要减少布局层级、减少主线程耗时操作，这样可以减少丢帧。如果丢帧比较严重，那么界面可能会有明显的卡顿感。我们知道 通常手机刷新是每秒60次，即每隔16.6ms刷新一次。 问题来了：
丢帧(掉帧) ，是说 这一帧延迟显示 还是丢弃不再显示 ？
布局层级较多/主线程耗时 是如何造成 丢帧的呢？
16.6ms刷新一次 是啥意思？是每16.6ms都走一次 measure/layout/draw ？
measure/layout/draw 走完，界面就立刻刷新了吗?
如果界面没动静止了，还会刷新吗？
可能你知道VSYNC，这个具体指啥？在屏幕刷新中如何工作的？
可能你还听过屏幕刷新使用 双缓存、三缓存，这又是啥意思呢？
可能你还听过神秘的Choreographer，这又是干啥的？
小朋友，你是否有很多问号？
本文介绍的内容会详细解释以上问题，并在最后给解答。稳住，别慌~
二、显示系统基础知识
在一个典型的显示系统中，一般包括CPU、GPU、Display三个部分， CPU负责计算帧数据，把计算好的数据交给GPU，GPU会对图形数据进行渲染，渲染好后放到buffer(图像缓冲区)里存起来，然后Display（屏幕或显示器）负责把buffer里的数据呈现到屏幕上。如下图：
2.1 基础概念
屏幕刷新频率
一秒内屏幕刷新的次数（一秒内显示了多少帧的图像），单位 Hz（赫兹），如常见的 60 Hz。刷新频率取决于硬件的固定参数（不会变的）。逐行扫描
显示器并不是一次性将画面显示到屏幕上，而是从左到右边，从上到下逐行扫描，顺序显示整屏的一个个像素点，不过这一过程快到人眼无法察觉到变化。以 60 Hz 刷新率的屏幕为例，这一过程即 1000 / 60 ≈ 16ms。帧率 （Frame Rate）
表示 GPU 在一秒内绘制操作的帧数，单位 fps。例如在电影界采用 24 帧的速度足够使画面运行的非常流畅。而 Android 系统则采用更加流程的 60 fps，即每秒钟GPU最多绘制 60 帧画面。帧率是动态变化的，例如当画面静止时，GPU 是没有绘制操作的，屏幕刷新的还是buffer中的数据，即GPU最后操作的帧数据。画面撕裂（tearing）
一个屏幕内的数据来自2个不同的帧，画面会出现撕裂感，如下图
2.2 双缓存
2.2.1 画面撕裂 原因
屏幕刷新频是固定的，比如每16.6ms从buffer取数据显示完一帧，理想情况下帧率和刷新频率保持一致，即每绘制完成一帧，显示器显示一帧。但是CPU/GPU写数据是不可控的，所以会出现buffer里有些数据根本没显示出来就被重写了，即buffer里的数据可能是来自不同的帧的， 当屏幕刷新时，此时它并不知道buffer的状态，因此从buffer抓取的帧并不是完整的一帧画面，即出现画面撕裂。
简单说就是Display在显示的过程中，buffer内数据被CPU/GPU修改，导致画面撕裂。
2.2.2 双缓存
那咋解决画面撕裂呢？答案是使用 双缓存。
由于图像绘制和屏幕读取 使用的是同个buffer，所以屏幕刷新时可能读取到的是不完整的一帧画面。
双缓存，让绘制和显示器拥有各自的buffer：GPU 始终将完成的一帧图像数据写入到 Back Buffer，而显示器使用 Frame Buffer，当屏幕刷新时，Frame Buffer 并不会发生变化，当Back buffer准备就绪后，它们才进行交换。如下图：
2.2.3 VSync
问题又来了：什么时候进行两个buffer的交换呢？
假如是 Back buffer准备完成一帧数据以后就进行，那么如果此时屏幕还没有完整显示上一帧内容的话，肯定是会出问题的。看来只能是等到屏幕处理完一帧数据后，才可以执行这一操作了。
当扫描完一个屏幕后，设备需要重新回到第一行以进入下一次的循环，此时有一段时间空隙，称为VerticalBlanking Interval(VBI)。那，这个时间点就是我们进行缓冲区交换的最佳时间。因为此时屏幕没有在刷新，也就避免了交换过程中出现 screen tearing的状况。
VSync(垂直同步)是VerticalSynchronization的简写，它利用VBI时期出现的vertical sync pulse（垂直同步脉冲）来保证双缓冲在最佳时间点才进行交换。另外，交换是指各自的内存地址，可以认为该操作是瞬间完成。
所以说V-sync这个概念并不是Google首创的，它在早年的PC机领域就已经出现了。
三、Android屏幕刷新机制
3.1 Android4.1之前的问题
具体到Android中，在Android4.1之前，屏幕刷新也遵循 上面介绍的 双缓存+VSync 机制。如下图：
以时间的顺序来看下将会发生的过程：
Display显示第0帧数据，此时CPU和GPU渲染第1帧画面，且在Display显示下一帧前完成
因为渲染及时，Display在第0帧显示完成后，也就是第1个VSync后，缓存进行交换，然后正常显示第1帧
接着第2帧开始处理，是直到第2个VSync快来前才开始处理的。
第2个VSync来时，由于第2帧数据还没有准备就绪，缓存没有交换，显示的还是第1帧。这种情况被Android开发组命名为“Jank”，即发生了丢帧。
当第2帧数据准备完成后，它并不会马上被显示，而是要等待下一个VSync 进行缓存交换再显示。
所以总的来说，就是屏幕平白无故地多显示了一次第1帧。
原因是 第2帧的CPU/GPU计算 没能在VSync信号到来前完成 。
我们知道，双缓存的交换 是在Vsyn到来时进行，交换后屏幕会取Frame buffer内的新数据，而实际 此时的Back buffer 就可以供GPU准备下一帧数据了。如果 Vsyn到来时 CPU/GPU就开始操作的话，是有完整的16.6ms的，这样应该会基本避免jank的出现了（除非CPU/GPU计算超过了16.6ms）。 那如何让 CPU/GPU计算在 Vsyn到来时进行呢？
3.2 drawing with VSync
为了优化显示性能，Google在Android 4.1系统中对Android Display系统进行了重构，实现了Project Butter（黄油工程）：系统在收到VSync pulse后，将马上开始下一帧的渲染。即一旦收到VSync通知（16ms触发一次），CPU和GPU 才立刻开始计算然后把数据写入buffer。如下图：
CPU/GPU根据VSYNC信号同步处理数据，可以让CPU/GPU有完整的16ms时间来处理数据，减少了jank。
一句话总结，VSync同步使得CPU/GPU充分利用了16.6ms时间，减少jank。
问题又来了，如果界面比较复杂，CPU/GPU的处理时间较长 超过了16.6ms呢？如下图：
在第二个时间段内，但却因 GPU 还在处理 B 帧，缓存没能交换，导致 A 帧被重复显示。
而B完成后，又因为缺乏VSync pulse信号，它只能等待下一个signal的来临。于是在这一过程中，有一大段时间是被浪费的。
当下一个VSync出现时，CPU/GPU马上执行操作（A帧），且缓存交换，相应的显示屏对应的就是B。这时看起来就是正常的。只不过由于执行时间仍然超过16ms，导致下一次应该执行的缓冲区交换又被推迟了——如此循环反复，便出现了越来越多的“Jank”。
为什么 CPU 不能在第二个 16ms 处理绘制工作呢？
原因是只有两个 buffer，Back buffer正在被GPU用来处理B帧的数据， Frame buffer的内容用于Display的显示，这样两个buffer都被占用，CPU 则无法准备下一帧的数据。那么，如果再提供一个buffer，CPU、GPU 和显示设备都能使用各自的buffer工作，互不影响。
3.3 三缓存
三缓存就是在双缓冲机制基础上增加了一个 Graphic Buffer 缓冲区，这样可以最大限度的利用空闲时间，带来的坏处是多使用的一个 Graphic Buffer 所占用的内存。
第一个Jank，是不可避免的。但是在第二个 16ms 时间段，CPU/GPU 使用 第三个 Buffer 完成C帧的计算，虽然还是会多显示一次 A 帧，但后续显示就比较顺畅了，有效避免 Jank 的进一步加剧。
注意在第3段中，A帧的计算已完成，但是在第4个vsync来的时候才显示，如果是双缓冲，那在第三个vynsc就可以显示了。
三缓冲有效利用了等待vysnc的时间，减少了jank，但是带来了延迟。 所以，是不是 Buffer 越多越好呢？这个是否定的，Buffer 正常还是两个，当出现 Jank 后三个足以。
以上就是Android屏幕刷新的原理了。
四、Choreographer
4.1 概述
上面讲到，Google在Android 4.1系统中对Android Display系统进行了优化：在收到VSync pulse后，将马上开始下一帧的渲染。即一旦收到VSync通知，CPU和GPU就立刻开始计算然后把数据写入buffer。本节就来讲 "drawing with VSync" 的实现——Choreographer。
Choreographer，意为 舞蹈编导、编舞者。在这里就是指 对CPU/GPU绘制的指导—— 收到VSync信号 才开始绘制，保证绘制拥有完整的16.6ms，避免绘制的随机性。
Choreographer，是一个Java类，包路径android.view.Choreographer。类注释是“协调动画、输入和绘图的计时”。
通常 应用层不会直接使用Choreographer，而是使用更高级的API，例如动画和View绘制相关的ValueAnimator.start()、View.invalidate()等。
业界一般通过Choreographer来监控应用的帧率。
4.2 源码分析
学习 Choreographer 可以帮助理解 每帧运行的原理，也可加深对 Handler机制、View绘制流程的理解，这样再去做UI优化、卡顿优化，思路会更清晰。
好了，下面开始源码分析了~
4.2.1 入口 和 实例创建
在《Window和WindowManager》、《Activity的启动过程详解》中介绍过，Activity启动 走完onResume方法后，会进行window的添加。window添加过程会 调用ViewRootImpl的setView()方法，setView()方法会调用requestLayout()方法来请求绘制布局，requestLayout()方法内部又会走到scheduleTraversals()方法，最后会走到performTraversals()方法，接着到了我们熟知的测量、布局、绘制三大流程了。
另外，查看源码发现，当我们使用 ValueAnimator.start()、View.invalidate()时，最后也是走到ViewRootImpl的scheduleTraversals()方法。（View.invalidate()内部会循环获取ViewParent直到ViewRootImpl的invalidateChildInParent()方法，然后走到scheduleTraversals()，可自行查看源码 ）
即 所有UI的变化都是走到ViewRootImpl的scheduleTraversals()方法。
那么问题又来了，scheduleTraversals() 到 performTraversals() 中间 经历了什么呢？是立刻执行吗？答案很显然是否定的，根据我们上面的介绍，在VSync信号到来时才会执行绘制，即performTraversals()方法。下面来瞅瞅这是如何实现的：
1 //ViewRootImpl.java
2 void scheduleTraversals() {
3 if (!mTraversalScheduled) {
4 //此字段保证同时间多次更改只会刷新一次，例如TextView连续两次setText(),也只会走一次绘制流程
5 mTraversalScheduled = true;
6 //添加同步屏障，屏蔽同步消息，保证VSync到来立即执行绘制
7 mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
8 //mTraversalRunnable是TraversalRunnable实例，最终走到run()，也即doTraversal();
9 mChoreographer.postCallback(
10 Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
11 if (!mUnbufferedInputDispatch) {
12 scheduleConsumeBatchedInput();
13 }
14 notifyRendererOfFramePending();
15 pokeDrawLockIfNeeded();
16 }
17 }
18
19 final class TraversalRunnable implements Runnable {
20 @Override
21 public void run() {
22 doTraversal();
23 }
24 }
25 final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
26
27 void doTraversal() {
28 if (mTraversalScheduled) {
29 mTraversalScheduled = false;
30 //移除同步屏障
31 mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
32 ...
33 //开始三大绘制流程
34 performTraversals();
35 ...
36 }
37 }
主要有以下逻辑：
首先使用mTraversalScheduled字段保证同时间多次更改只会刷新一次，例如TextView连续两次setText()，也只会走一次绘制流程。
然后把当前线程的消息队列Queue添加了同步屏障，这样就屏蔽了正常的同步消息，保证VSync到来后立即执行绘制，而不是要等前面的同步消息。后面会具体分析同步屏障和异步消息的代码逻辑。
调用了mChoreographer.postCallback()方法，发送一个会在下一帧执行的回调，即在下一个VSync到来时会执行TraversalRunnable-->doTraversal()--->performTraversals()-->绘制流程。
接下来，就是分析的重点——Choreographer。我们先看它的实例mChoreographer，是在ViewRootImpl的构造方法内使用Choreographer.getInstance()创建：
1Choreographer mChoreographer;
2
3//ViewRootImpl实例是在添加window时创建
4public ViewRootImpl(Context context, Display display) {
5 ...
6 mChoreographer = Choreographer.getInstance();
7 ...
8}
我们先来看看Choreographer.getInstance()：
1 public static Choreographer getInstance() {
2 return sThreadInstance.get();
3 }
4
5 private static final ThreadLocal<Choreographer> sThreadInstance =
6 new ThreadLocal<Choreographer>() {
7 @Override
8 protected Choreographer initialValue() {
9 Looper looper = Looper.myLooper();
10 if (looper == null) {
11 //当前线程要有looper，Choreographer实例需要传入
12 throw new IllegalStateException("The current thread must have a looper!");
13 }
14 Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
15 if (looper == Looper.getMainLooper()) {
16 mMainInstance = choreographer;
17 }
18 return choreographer;
19 }
20 };
看到这里 如你对Handler机制中looper比较熟悉的话，应该知道 Choreographer和Looper一样 是线程单例的。且当前线程要有looper，Choreographer实例需要传入。接着看看Choreographer构造方法：
1 private Choreographer(Looper looper, int vsyncSource) {
2 mLooper = looper;
3 //使用当前线程looper创建 mHandler
4 mHandler = new FrameHandler(looper);
5 //USE_VSYNC 4.1以上默认是true，表示 具备接受VSync的能力，这个接受能力就是FrameDisplayEventReceiver
6 mDisplayEventReceiver = USE_VSYNC
7 ? new FrameDisplayEventReceiver(looper, vsyncSource)
8 : null;
9 mLastFrameTimeNanos = Long.MIN_VALUE;
10
11 // 计算一帧的时间，Android手机屏幕是60Hz的刷新频率，就是16ms
12 mFrameIntervalNanos = (long)(1000000000 / getRefreshRate());
13
14 // 创建一个链表类型CallbackQueue的数组，大小为5，
15 //也就是数组中有五个链表，每个链表存相同类型的任务：输入、动画、遍历绘制等任务（CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL）
16 mCallbackQueues = new CallbackQueue[CALLBACK_LAST + 1];
17 for (int i = 0; i <= CALLBACK_LAST; i++) {
18 mCallbackQueues[i] = new CallbackQueue();
19 }
20 // b/68769804: For low FPS experiments.
21 setFPSDivisor(SystemProperties.getInt(ThreadedRenderer.DEBUG_FPS_DIVISOR, 1));
22 }
代码中都有注释，创建了一个mHandler、VSync事件接收器mDisplayEventReceiver、任务链表数组mCallbackQueues。FrameHandler、FrameDisplayEventReceiver、CallbackQueue后面会一一说明。
4.2.2 安排任务—postCallback
回头看mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null)方法，注意到第一个参数是CALLBACK_TRAVERSAL，表示回调任务的类型，共有以下5种类型：
1 //输入事件，首先执行
2 public static final int CALLBACK_INPUT = 0;
3 //动画，第二执行
4 public static final int CALLBACK_ANIMATION = 1;
5 //插入更新的动画，第三执行
6 public static final int CALLBACK_INSETS_ANIMATION = 2;
7 //绘制，第四执行
8 public static final int CALLBACK_TRAVERSAL = 3;
9 //提交，最后执行，
10 public static final int CALLBACK_COMMIT = 4;
五种类型任务对应存入对应的CallbackQueue中，每当收到 VSYNC 信号时，Choreographer 将首先处理 INPUT 类型的任务，然后是 ANIMATION 类型，最后才是 TRAVERSAL 类型。
postCallback()内部调用postCallbackDelayed()，接着又调用postCallbackDelayedInternal()，来瞅瞅：
1 private void postCallbackDelayedInternal(int callbackType,
2 Object action, Object token, long delayMillis) {
3 ...
4 synchronized (mLock) {
5 // 当前时间
6 final long now = SystemClock.uptimeMillis();
7 // 加上延迟时间
8 final long dueTime = now + delayMillis;
9 //取对应类型的CallbackQueue添加任务
10 mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);
11
12 if (dueTime <= now) {
13 //立即执行
14 scheduleFrameLocked(now);
15 } else {
16 //延迟运行，最终也会走到scheduleFrameLocked()
17 Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
18 msg.arg1 = callbackType;
19 msg.setAsynchronous(true);
20 mHandler.sendMessageAtTime(msg, dueTime);
21 }
22 }
23 }
首先取对应类型的CallbackQueue添加任务，action就是mTraversalRunnable，token是null。CallbackQueue的addCallbackLocked()就是把 dueTime、action、token组装成CallbackRecord后 存入CallbackQueue的下一个节点，具体代码比较简单，不再跟进。
然后注意到如果没有延迟会执行scheduleFrameLocked()方法，有延迟就会使用 mHandler发送MSG_DO_SCHEDULE_CALLBACK消息，并且注意到 使用msg.setAsynchronous(true)把消息设置成异步，这是因为前面设置了同步屏障，只有异步消息才会执行。我们看下mHandler的对这个消息的处理：
1 private final class FrameHandler extends Handler {
2 public FrameHandler(Looper looper) {
3 super(looper);
4 }
5 @Override
6 public void handleMessage(Message msg) {
7 switch (msg.what) {
8 case MSG_DO_FRAME:
9 // 执行doFrame,即绘制过程
10 doFrame(System.nanoTime(), 0);
11 break;
12 case MSG_DO_SCHEDULE_VSYNC:
13 //申请VSYNC信号，例如当前需要绘制任务时
14 doScheduleVsync();
15 break;
16 case MSG_DO_SCHEDULE_CALLBACK:
17 //需要延迟的任务，最终还是执行上述两个事件
18 doScheduleCallback(msg.arg1);
19 break;
20 }
21 }
22 }
直接使用doScheduleCallback方法，看看：
1 void doScheduleCallback(int callbackType) {
2 synchronized (mLock) {
3 if (!mFrameScheduled) {
4 final long now = SystemClock.uptimeMillis();
5 if (mCallbackQueues[callbackType].hasDueCallbacksLocked(now)) {
6 scheduleFrameLocked(now);
7 }
8 }
9 }
10 }
发现也是走到这里，即延迟运行最终也会走到scheduleFrameLocked()，跟进看看：
1 private void scheduleFrameLocked(long now) {
2 if (!mFrameScheduled) {
3 mFrameScheduled = true;
4 //开启了VSYNC
5 if (USE_VSYNC) {
6 if (DEBUG_FRAMES) {
7 Log.d(TAG, "Scheduling next frame on vsync.");
8 }
9
10 //当前执行的线程，是否是mLooper所在线程
11 if (isRunningOnLooperThreadLocked()) {
12 //申请 VSYNC 信号
13 scheduleVsyncLocked();
14 } else {
15 // 若不在，就用mHandler发送消息到原线程，最后还是调用scheduleVsyncLocked方法
16 Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
17 msg.setAsynchronous(true);//异步
18 mHandler.sendMessageAtFrontOfQueue(msg);
19 }
20 } else {
21 // 如果未开启VSYNC则直接doFrame方法（4.1后默认开启）
22 final long nextFrameTime = Math.max(
23 mLastFrameTimeNanos / TimeUtils.NANOS_PER_MS + sFrameDelay, now);
24 if (DEBUG_FRAMES) {
25 Log.d(TAG, "Scheduling next frame in " + (nextFrameTime - now) + " ms.");
26 }
27 Message msg = mHandler.obtainMessage(MSG_DO_FRAME);
28 msg.setAsynchronous(true);//异步
29 mHandler.sendMessageAtTime(msg, nextFrameTime);
30 }
31 }
32 }
如果系统未开启 VSYNC 机制，此时直接发送 MSG_DO_FRAME 消息到 FrameHandler。注意查看上面贴出的 FrameHandler 代码，此时直接执行 doFrame 方法。
Android 4.1 之后系统默认开启 VSYNC，在 Choreographer 的构造方法会创建一个 FrameDisplayEventReceiver，scheduleVsyncLocked 方法将会通过它申请 VSYNC 信号。
isRunningOnLooperThreadLocked 方法，其内部根据 Looper 判断是否在原线程，否则发送消息到 FrameHandler。最终还是会调用 scheduleVsyncLocked 方法申请 VSYNC 信号。
到这里，FrameHandler的作用很明显里了：发送异步消息（因为前面设置了同步屏障）。有延迟的任务发延迟消息、不在原线程的发到原线程、没开启VSYNC的直接走 doFrame 方法取执行绘制。
4.2.3 申请和接受VSync
好了， 接着就看 scheduleVsyncLocked 方法是如何申请 VSYNC 信号的。猜测肯定申请 VSYNC 信号后，信号到来时也是走doFrame() 方法，doFrame()后面再看。先跟进scheduleVsyncLocked():
1 private void scheduleVsyncLocked() {
2 mDisplayEventReceiver.scheduleVsync();
3 }
很简单，调用mDisplayEventReceiver的scheduleVsync()方法，mDisplayEventReceiver是Choreographer构造方法中创建，是FrameDisplayEventReceiver 的实例。FrameDisplayEventReceiver是 DisplayEventReceiver 的子类，DisplayEventReceiver 是一个 abstract class：
1 public DisplayEventReceiver(Looper looper, int vsyncSource) {
2 if (looper == null) {
3 throw new IllegalArgumentException("looper must not be null");
4 }
5
6 mMessageQueue = looper.getQueue();
7 // 注册VSYNC信号监听者
8 mReceiverPtr = nativeInit(new WeakReference<DisplayEventReceiver>(this), mMessageQueue,
9 vsyncSource);
10
11 mCloseGuard.open("dispose");
12 }
在 DisplayEventReceiver 的构造方法会通过 JNI 创建一个 IDisplayEventConnection 的 VSYNC 的监听者。
FrameDisplayEventReceiver的scheduleVsync()就是在 DisplayEventReceiver中：
1 public void scheduleVsync() {
2 if (mReceiverPtr == 0) {
3 Log.w(TAG, "Attempted to schedule a vertical sync pulse but the display event "
4 + "receiver has already been disposed.");
5 } else {
6 // 申请VSYNC中断信号，会回调onVsync方法
7 nativeScheduleVsync(mReceiverPtr);
8 }
9 }
那么scheduleVsync()就是使用native方法nativeScheduleVsync()去申请VSYNC信号。这个native方法就看不了了，只需要知道VSYNC信号的接受回调是onVsync()，我们直接看onVsync()：
1 /**
2 * 接收到VSync脉冲时 回调
3 * @param timestampNanos VSync脉冲的时间戳
4 * @param physicalDisplayId Stable display ID that uniquely describes a (display, port) pair.
5 * @param frame 帧号码，自增
6 */
7 @UnsupportedAppUsage
8 public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
9 }
具体实现是在FrameDisplayEventReceiver中：
1 private final class FrameDisplayEventReceiver extends DisplayEventReceiver
2 implements Runnable {
3 private boolean mHavePendingVsync;
4 private long mTimestampNanos;
5 private int mFrame;
6
7 public FrameDisplayEventReceiver(Looper looper, int vsyncSource) {
8 super(looper, vsyncSource);
9 }
10
11 @Override
12 public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
13 // Post the vsync event to the Handler.
14 // The idea is to prevent incoming vsync events from completely starving
15 // the message queue. If there are no messages in the queue with timestamps
16 // earlier than the frame time, then the vsync event will be processed immediately.
17 // Otherwise, messages that predate the vsync event will be handled first.
18 long now = System.nanoTime();
19 if (timestampNanos > now) {
20 Log.w(TAG, "Frame time is " + ((timestampNanos - now) * 0.000001f)
21 + " ms in the future! Check that graphics HAL is generating vsync "
22 + "timestamps using the correct timebase.");
23 timestampNanos = now;
24 }
25
26 if (mHavePendingVsync) {
27 Log.w(TAG, "Already have a pending vsync event. There should only be "
28 + "one at a time.");
29 } else {
30 mHavePendingVsync = true;
31 }
32
33 mTimestampNanos = timestampNanos;
34 mFrame = frame;
35 //将本身作为runnable传入msg， 发消息后 会走run()，即doFrame()，也是异步消息
36 Message msg = Message.obtain(mHandler, this);
37 msg.setAsynchronous(true);
38 mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
39 }
40
41 @Override
42 public void run() {
43 mHavePendingVsync = false;
44 doFrame(mTimestampNanos, mFrame);
45 }
46 }
onVsync()中，将接收器本身作为runnable传入异步消息msg，并使用mHandler发送msg，最终执行的就是doFrame()方法了。
注意一点是，onVsync()方法中只是使用mHandler发送消息到MessageQueue中，不一定是立刻执行，如何MessageQueue中前面有较为耗时的操作，那么就要等完成，才会执行本次的doFrame()。
4.2.4 doFrame
和上面猜测一样，申请VSync信号接收到后确实是走 doFrame()方法，那么就来看看Choreographer的doFrame()：
1 void doFrame(long frameTimeNanos, int frame) {
2 final long startNanos;
3 synchronized (mLock) {
4 if (!mFrameScheduled) {
5 return; // no work to do
6 }
7
8 ...
9 // 预期执行时间
10 long intendedFrameTimeNanos = frameTimeNanos;
11 startNanos = System.nanoTime();
12 // 超时时间是否超过一帧的时间（这是因为MessageQueue虽然添加了同步屏障，但是还是有正在执行的同步任务，导致doFrame延迟执行了）
13 final long jitterNanos = startNanos - frameTimeNanos;
14 if (jitterNanos >= mFrameIntervalNanos) {
15 // 计算掉帧数
16 final long skippedFrames = jitterNanos / mFrameIntervalNanos;
17 if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
18 // 掉帧超过30帧打印Log提示
19 Log.i(TAG, "Skipped " + skippedFrames + " frames! "
20 + "The application may be doing too much work on its main thread.");
21 }
22 final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;
23 ...
24 frameTimeNanos = startNanos - lastFrameOffset;
25 }
26
27 ...
28
29 mFrameInfo.setVsync(intendedFrameTimeNanos, frameTimeNanos);
30 // Frame标志位恢复
31 mFrameScheduled = false;
32 // 记录最后一帧时间
33 mLastFrameTimeNanos = frameTimeNanos;
34 }
35
36 try {
37 // 按类型顺序 执行任务
38 Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame");
39 AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);
40
41 mFrameInfo.markInputHandlingStart();
42 doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
43
44 mFrameInfo.markAnimationsStart();
45 doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
46 doCallbacks(Choreographer.CALLBACK_INSETS_ANIMATION, frameTimeNanos);
47
48 mFrameInfo.markPerformTraversalsStart();
49 doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
50
51 doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
52 } finally {
53 AnimationUtils.unlockAnimationClock();
54 Trace.traceEnd(Trace.TRACE_TAG_VIEW);
55 }
56 }
上面都有注释了很好理解，接着看任务的具体执行doCallbacks 方法：
1 void doCallbacks(int callbackType, long frameTimeNanos) {
2 CallbackRecord callbacks;
3 synchronized (mLock) {
4
5 final long now = System.nanoTime();
6 // 根据指定的类型CallbackkQueue中查找到达执行时间的CallbackRecord
7 callbacks = mCallbackQueues[callbackType].extractDueCallbacksLocked(now / TimeUtils.NANOS_PER_MS);
8 if (callbacks == null) {
9 return;
10 }
11 mCallbacksRunning = true;
12
13 //提交任务类型
14 if (callbackType == Choreographer.CALLBACK_COMMIT) {
15 final long jitterNanos = now - frameTimeNanos;
16 if (jitterNanos >= 2 * mFrameIntervalNanos) {
17 final long lastFrameOffset = jitterNanos % mFrameIntervalNanos
18 + mFrameIntervalNanos;
19 if (DEBUG_JANK) {
20 Log.d(TAG, "Commit callback delayed by " + (jitterNanos * 0.000001f)
21 + " ms which is more than twice the frame interval of "
22 + (mFrameIntervalNanos * 0.000001f) + " ms! "
23 + "Setting frame time to " + (lastFrameOffset * 0.000001f)
24 + " ms in the past.");
25 mDebugPrintNextFrameTimeDelta = true;
26 }
27 frameTimeNanos = now - lastFrameOffset;
28 mLastFrameTimeNanos = frameTimeNanos;
29 }
30 }
31 }
32 try {
33 // 迭代执行队列所有任务
34 for (CallbackRecord c = callbacks; c != null; c = c.next) {
35 // 回调CallbackRecord的run，其内部回调Callback的run
36 c.run(frameTimeNanos);
37 }
38 } finally {
39 synchronized (mLock) {
40 mCallbacksRunning = false;
41 do {
42 final CallbackRecord next = callbacks.next;
43 //回收CallbackRecord
44 recycleCallbackLocked(callbacks);
45 callbacks = next;
46 } while (callbacks != null);
47 }
48 }
49 }
主要内容就是取对应任务类型的队列，遍历队列执行所有任务，执行任务是 CallbackRecord的 run 方法：
1 private static final class CallbackRecord {
2 public CallbackRecord next;
3 public long dueTime;
4 public Object action; // Runnable or FrameCallback
5 public Object token;
6
7 @UnsupportedAppUsage
8 public void run(long frameTimeNanos) {
9 if (token == FRAME_CALLBACK_TOKEN) {
10 // 通过postFrameCallback 或 postFrameCallbackDelayed，会执行这里
11 ((FrameCallback)action).doFrame(frameTimeNanos);
12 } else {
13 //取出Runnable执行run()
14 ((Runnable)action).run();
15 }
16 }
17 }
前面看到mChoreographer.postCallback传的token是null，所以取出action，就是Runnable，执行run()，这里的action就是 ViewRootImpl 发起的绘制任务mTraversalRunnable了，那么这样整个逻辑就闭环了。
那么 啥时候 token == FRAME_CALLBACK_TOKEN 呢？答案是Choreographer的postFrameCallback()方法：
1 public void postFrameCallback(FrameCallback callback) {
2 postFrameCallbackDelayed(callback, 0);
3 }
4
5 public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {
6 if (callback == null) {
7 throw new IllegalArgumentException("callback must not be null");
8 }
9
10 //也是走到是postCallbackDelayedInternal，并且注意是CALLBACK_ANIMATION类型，
11 //token是FRAME_CALLBACK_TOKEN，action就是FrameCallback
12 postCallbackDelayedInternal(CALLBACK_ANIMATION,
13 callback, FRAME_CALLBACK_TOKEN, delayMillis);
14 }
15
16 public interface FrameCallback {
17 public void doFrame(long frameTimeNanos);
18 }
可以看到postFrameCallback()传入的是FrameCallback实例，接口FrameCallback只有一个doFrame()方法。并且也是走到postCallbackDelayedInternal，FrameCallback实例作为action传入，token则是FRAME_CALLBACK_TOKEN，并且任务是CALLBACK_ANIMATION类型。
Choreographer的postFrameCallback()通常用来计算丢帧情况，使用方式如下：
1 //Application.java
2 public void onCreate() {
3 super.onCreate();
4 //在Application中使用postFrameCallback
5 Choreographer.getInstance().postFrameCallback(new FPSFrameCallback(System.nanoTime()));
6 }
7
8
9 public class FPSFrameCallback implements Choreographer.FrameCallback {
10
11 private static final String TAG = "FPS_TEST";
12 private long mLastFrameTimeNanos = 0;
13 private long mFrameIntervalNanos;
14
15 public FPSFrameCallback(long lastFrameTimeNanos) {
16 mLastFrameTimeNanos = lastFrameTimeNanos;
17 mFrameIntervalNanos = (long)(1000000000 / 60.0);
18 }
19
20 @Override
21 public void doFrame(long frameTimeNanos) {
22
23 //初始化时间
24 if (mLastFrameTimeNanos == 0) {
25 mLastFrameTimeNanos = frameTimeNanos;
26 }
27 final long jitterNanos = frameTimeNanos - mLastFrameTimeNanos;
28 if (jitterNanos >= mFrameIntervalNanos) {
29 final long skippedFrames = jitterNanos / mFrameIntervalNanos;
30 if(skippedFrames>30){
31 //丢帧30以上打印日志
32 Log.i(TAG, "Skipped " + skippedFrames + " frames! "
33 + "The application may be doing too much work on its main thread.");
34 }
35 }
36 mLastFrameTimeNanos=frameTimeNanos;
37 //注册下一帧回调
38 Choreographer.getInstance().postFrameCallback(this);
39 }
40 }
4.2.5 小结
使用Choreographer的postCallback()、postFrameCallback() 作用理解：发送任务 存队列中，监听VSync信号，当前VSync到来时 会使用mHandler发送异步message，这个message的Runnable就是队列中的所有任务。
好了，Choreographer整个代码逻辑都讲完了，引用《Android 之 Choreographer 详细分析》的流程图：
五、Handler异步消息与同步屏障
最后来介绍下异步消息与同步屏障。
在Handler中，Message分为3种：同步消息、异步消息、同步屏障消息，他们三者都是Message，只是属性有些区别。
5.1异步消息
通常我们使用创建Handler方式如下：
1 public Handler() {
2 this(null, false);
3 }
注意到内部使用了两个两个参数的构造方法，其中第二个是false：
1 public Handler(@Nullable Callback callback, boolean async) {
2 ...
3 mLooper = Looper.myLooper();
4 if (mLooper == null) {
5 throw new RuntimeException(
6 "Can't create handler inside thread " + Thread.currentThread()
7 + " that has not called Looper.prepare()");
8 }
9 mQueue = mLooper.mQueue;
10 mCallback = callback;
11 //异步标志
12 mAsynchronous = async;
13 }
这个false就表示 非异步，即使用的是同步消息，mAsynchronous使用是在enqueueMessage()中：
1private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
2 //将Handler赋值给Message的target变量
3 msg.target = this;
4 //mAsynchronous为false，为同步消息
5 if (mAsynchronous) {
6 msg.setAsynchronous(true);
7 }
8 return queue.enqueueMessage(msg, uptimeMillis);
9}
这里如果mAsynchronous是true，就会使用msg.setAsynchronous(true)设置为异步消息。所以上面Choreographer中使用的都是异步消息。
5.2同步屏障消息
postSyncBarrier()方法就是用来插入一个屏障到消息队列的，
1 //MessageQueue
2 public int postSyncBarrier() {
3 return postSyncBarrier(SystemClock.uptimeMillis());
4 }
5
6 private int postSyncBarrier(long when) {
7 synchronized (this) {
8 final int token = mNextBarrierToken++;
9 //注意这里 没有tartget赋值
10 final Message msg = Message.obtain();
11 msg.markInUse();
12 msg.when = when;
13 msg.arg1 = token;
14
15 Message prev = null;
16 Message p = mMessages;
17 if (when != 0) {
18 while (p != null && p.when <= when) {
19 prev = p;
20 p = p.next;
21 }
22 }
23 if (prev != null) { // invariant: p == prev.next
24 msg.next = p;
25 prev.next = msg;
26 } else {
27 msg.next = p;
28 mMessages = msg;
29 }
30 return token;
31 }
32 }
可以看到它很简单，从这个方法我们可以知道如下：
屏障消息和普通消息的区别在于屏障没有tartget，普通消息有target是因为它需要将消息分发给对应的target，而屏障不需要被分发，它就是用来挡住普通消息来保证异步消息优先处理的。
屏障和普通消息一样可以根据时间来插入到消息队列中的适当位置，并且只会挡住它后面的同步消息的分发
postSyncBarrier()返回一个int类型的数值，通过这个数值可以撤销屏障即removeSyncBarrier()。
postSyncBarrier()是私有的，如果我们想调用它就得使用反射。插入普通消息会唤醒消息队列，但是插入屏障不会。
5.3 原理
同步屏障消息 是如何 挡住普通消息来保证异步消息优先处理的？我们看看MessageQueue的next()方法：
1 //MessageQueue.java
2 Message next() {
3 ...
4 for (;;) {
5 ...
6 synchronized (this) {
7 // Try to retrieve the next message. Return if found.
8 final long now = SystemClock.uptimeMillis();
9 Message prevMsg = null;
10 Message msg = mMessages;
11 if (msg != null && msg.target == null) {
12 // msg.target == null 就是同步屏障消息，那么只取异步消息
13 do {
14 prevMsg = msg;
15 msg = msg.next;
16 } while (msg != null && !msg.isAsynchronous());
17 }
18 if (msg != null) {
19 if (now < msg.when) {
20 nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
21 } else {
22 // Got a message.
23 mBlocked = false;
24 if (prevMsg != null) {
25 prevMsg.next = msg.next;
26 } else {
27 mMessages = msg.next;
28 }
29 msg.next = null;
30 if (DEBUG) Log.v(TAG, "Returning message: " + msg);
31 msg.markInUse();
32 return msg;
33 }
34 } else {
35 // No more messages.
36 nextPollTimeoutMillis = -1;
37 }
38 ...
39 }
40 }
很简单，遍历消息队列时，发现了同步屏障消息，那么就只取异步消息了。
好了，相关知识终于讲完了。
六、疑问解答
丢帧(掉帧) ，是说 这一帧延迟显示 还是丢弃不再显示 ？
答：延迟显示，因为缓存交换的时机只能等下一个VSync了。布局层级较多/主线程耗时 是如何造成 丢帧的呢？
答：布局层级较多/主线程耗时 会影响CPU/GPU的执行时间，大于16.6ms时只能等下一个VSync了。16.6ms刷新一次 是啥意思？是每16.6ms都走一次 measure/layout/draw ？
答：屏幕的固定刷新频率是60Hz，即16.6ms。不是每16.6ms都走一次 measure/layout/draw，而是有绘制任务才会走，并且绘制时间间隔是取决于布局复杂度及主线程耗时。measure/layout/draw 走完，界面就立刻刷新了吗?
答：不是。measure/layout/draw 走完后 会在VSync到来时进行缓存交换和刷新。如果界面没动静止了，还会刷新吗？
答：屏幕会固定没16.6ms刷新，但CPU/GPU不走绘制流程。见下面的SysTrace图。可能你知道VSYNC，这个具体指啥？在屏幕刷新中如何工作的？
答：当扫描完一个屏幕后，设备需要重新回到第一行以进入下一次的循环，此时会出现的vertical sync pulse（垂直同步脉冲）来保证双缓冲在最佳时间点才进行交换。并且Android4.1后 CPU/GPU的绘制是在VSYNC到来时开始。可能你还听过屏幕刷新使用 双缓存、三缓存，这又是啥意思呢？
答：双缓存是Back buffer、Frame buffer，用于解决画面撕裂。三缓存增加一个Back buffer，用于减少Jank。可能你还听过神秘的Choreographer，这又是干啥的？
答：用于实现——"CPU/GPU的绘制是在VSYNC到来时开始"。
参考与感谢
android屏幕刷新显示机制
https://blog.csdn.net/litefish/article/details/53939882
Android图形显示系统（一）
https://www.jianshu.com/p/424918260fa9?open_source=weibo_search
Android 屏幕刷新机制
https://juejin.im/post/6844903585424097293
Android 之 Choreographer 详细分析
https://www.jianshu.com/p/86d00bbdaf60
Handler异步消息与同步屏障
https://www.jianshu.com/p/28fba43ac0b0
因为公众号比较新，没有留言功能，我找了留言小程序，可点击进行留言讨论~
推荐阅读:
嵌套滑动通用解决方案--NestedScrollingParent2
网络请求框架OkHttp3全解系列 - （二）OkHttp的工作流程分析